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CROSS-REFERENCES TO RELATED APPLICATIONS 
[0001] The present application is a divisional application of co-pending application Serial 
Number 10/167,532, filed on June 11, 2002, entitled "System and Method for Proactive Content 
Delivery By Situational Location," which is a continuation of application Serial Number 
09/589,328 filed on June 7, 2000, entitled "System and Method for Proactive Content Delivery 
By Situational Location," now U.S. Patent Number 6,456,234, issued September 24, 2002. 

STATEMENT AS TO RIGHTS TO INVENTIONS MADE UNDER 
FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
[0002] NOT APPLICABLE 

REFERENCE TO A "SEQUENCE LISTING," A TABLE, OR A COMPUTER 
PROGRAM LISTING APPENDIX SUBMITTED ON A COMPACT DISK. 
[0003] NOT APPLICABLE 

BACKGROUND OF THE INVENTION 
[0004] The present invention relates generally to location dependent delivery of information to 
mobile data processing systems, and more particularly to a system for pushing situational 
location dependent content to data processing system devices traveling to locations for, or in 
directions of, that place which delivery content is designated as deliverable. 

[0005] The boom of the internet has greatly provided information to mobile users through 
wireless web server connected devices such as laptops, personal digital assistants (PDAs), and 
telephones. People with an internet enabled device can access yahoo.com (yahoo is a trademark 
of Yahoo corporation) and other internet connected resources. There are also Global Positioning 
System (GPS) devices that enable mobile users to know exactly where they are on a particular 



map. Users with GPS device functionality can further manually enter their known location into 
an internet MAP directory service (e.g. yahoo.com Maps) and then provide a target address they 
want to go to. Step by step instructions are then provided tp the user for how to get to the 
destination from the current location. Some GPS devices provide local processing for directing, 
5 and narrating to, a driver. Mating automated location finding systems with internet travel 
direction services is an attractive blend. 

[0006] Cadillac recently announced the OnStar program with sales of Cadillac automobiles 
(Cadillac and OnStar are trademarks of General Motors corporation). A person is enabled with 
calling upon an "OnStar Advisor" 7 days a week, 24 hours a day, with the press of a button. An 

10 emergency call, for example 91 1, or for a disabled Cadillac vehicle, allows a driver to instantly 
call upon wireless connected assistance. The driver may also call upon the OnStar Advisor for 
directions to a destination. The Advisor has access to automatic processing for determination of 
the vehicle's current location in case of auto theft, a disabled vehicle, or assisting with directions. 
The Advisor can also remotely unlock the vehicle should the driver lock the keys in the car. In 

15 effect, Cadillac drivers have full time wireless connected assistance around the clock for many 
reasons. While the location determination of the vehicle is automatic, there remain manual 
processes performed by the Advisor. Automation of some of these processes is desirable. 

[0007] Many internet services derive their revenue stream from advertising. Advertisers pay to 
have their content delivered to users who access web site and web server interfaces. Advertisers 
20 desire to target their audience at the most appropriate time. Knowing the location of a user as 
being relevant to a particular advertisement is desirable. Automating the delivery of the content 
is desirable. 

[0008] A method is needed for a low cost business model that enables the efficient 
configuration of deliverable content for automatic delivery to mobile users based on their 
25 situational location that is relevant to receive such content. 

BRIEF SUMMARY OF THE INVENTION 
[0009] The present invention provides transmission -of situational location dependent 

information from a server data processing system (SDPS) to a receiving data processing system 
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(RDPS). The server data processing system (SDPS) communicates with the receiving data 
processing system (RDPS) by pushing content (i.e. proactive content delivery) when appropriate, 
rather than in response to a user query. A candidate delivery event associated with a current 
positional attribute of the receiving data processing system is recognized and a situational 
5 location of the remote data processing system is determined. The candidate delivery event may 
be a location and/or direction change, device state change,* or movement exceeding a movement 
tolerance. The situational location of the remote data processing system may be its location, 
direction, location and direction, proximity to a location, state change, or location and/or 
direction relative to a previous location and/or direction, or combinations thereof. At the SDPS, 

10 a set of delivery content from a deliverable content database is retrieved according to the 
situational location of the RDPS, and according to system delivery constraints and/or configured 
user delivery constraints. The SDPS transmits any applicable content found to the RDPS. The 
delivery content is configurable by authorized administrators in a manner that enables the 
configured content for immediate delivery should a RDPS meet the criteria of the associated 

15 situational location and delivery constraints. 

[0010] Various embodiments with respect to recognizing a candidate delivery event and 
determining a situational location include: 

• the SDPS recognizes the candidate delivery event (e.g. various wireless 
* embodiments and physical connection embodiments) 

20 • the RDPS recognizes the candidate delivery event (e.g. GPS and some 

wireless) 

• the SDPS determines the situational location associated with the candidate 
delivery event which may have been determined by the RDPS and 
communicated to the SDPS, or determined by the SDPS 

25 • the RDPS determines the situational location associated with the candidate 

delivery event and communicates the information to the SDPS for further 
processing 



[001 1] A situational location is completely determined for the RDPS upon the candidate 
delivery event. Content that can be delivered is fully configurable, of any type, and can be 
instantly activated for candidate delivery upon convenient administration. As well known in the 
art of software installation, the present invention may be installed to a variety of network 
5 embodiments and underlying operating systems through installation parameters, or as distinct 
installations for the particular platform. Preferably, an internet connection is used for 
configuring deliverable content, and for the interoperation of communications between the RDPS 
and SDPS. 

[0012] The present invention enables a user of a RDPS to be made aware of content that is 
10 applicable for the current situational location of the user. Depending on the application of the 
present invention, the content and configurations will take on a variety of themes. 

[0013] For example, in an outdoor wireless embodiment of the present invention, 
advertisement content can be configured by paying customer advertisers through an internet web 
interface, and then automatically delivered to people when the people are in a location, or 

1 5 heading path to a location, for reasonable delivery of the content to their automobile installed, or 
handheld, RDPS. For example, as a driver or pedestrian (i.e. user) approaches a retail store with 
a mobile RDPS, a configured advertisement of a special deal at the retail store can be proactively 
delivered (i.e. pushed) to the user automatically on behalf of the store. Likewise, an indoor 
wireless embodiment of the present invention enables the driver or pedestrian, now a shopper 

20 inside the store, to receive configured content to a shopping cart mounted, or handheld, RDPS 
directing the shopper to specific sales items as the shopper moves about the inside of the store. 

[0014] In another application, a policeman may activate a mobile police automobile device 
(i.e. RDPS) in a police car for automatic delivery of a person's criminal record as the policeman 
drives by the location of a person's house. The police establishment configures criminal record 
25 content, or pointers thereto, along with the location of the residence that is believed to harbor the 
person with a record. As the policeman drives by locations with addresses of known offenders, 
the RDPS displays applicable criminal data. Of course, the policeman can enable or disable the 
functionality as needed. 

[0015] In another application, a traveling vehicle, for example a touring bus, carries tourists for 
30 a narrated drive through a geographic area. Currently, there are human narrators for providing 
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narration of sites and landmarks to people of the narrated drive. The present invention allows 
configuring deliverable content for locations on the touring bus path so that an automated 
narrator RDPS installed in the bus can be provided to people on the bus. For example, an RDPS 
providing audio, video, multimedia, or combination thereof, communicates narration content to 
5 people on the touring bus automatically as locations are encountered, or driven by. 

[0016] In another application, a person attending a large park (e.g. Disney World (Disney 
World is a trademark of Walt Disney corporation)) could simply carry a RDPS, and receive 
content to a handheld device for what attraction lies ahead based on the current location and 
direction of the person. The person would not have to consult a directory or ask where to find 
1 0 something. Informative content would be proactively delivered, rather than reactively in 
response to a person's manual query to a service, or question to a human being. 

[0017] In yet a further example, a valuable use would be for emergencies such as when a child 
is kidnapped. Currently, there is an Amber- Alert mechanism in Dallas/Ft. Worth, Texas where 
radio stations broadcast an emergency message along with a distinguishable series of tones. This 
15 enables any pertinent information known about the kidnapper and child to be broadcast 
immediately to everyone with the radio on. The present invention enables the emergency 
broadcast to be immediately configured and then communicated to everyone with a RDPS, for 
example with a wireless internet connection. A picture of the victim and other multimedia 
information could be delivered along with audio immediately. 

20 [0018] In still a further use of the present invention, garage sale and estate sale advertisements 
could be configured on behalf of paying customers that would otherwise use a newspaper 
classified section. As drivers become in reasonably close proximity to the sale, in the desired 
time window, advertisement content would be proactively delivered to a wireless RDPS 
installed, or handheld, in the automobile. 

25 [0019] Thus, there are many applications for the present invention, all accomplished through 
simply changing the way the present invention is used. Content is pushed out to receiving 
devices at the most appropriate times. Users do not pull the content with a query. 

[0020] It is therefore an advantage of the present invention in supporting a variety of 
applications and uses. The way the invention is used makes it applicable to a wide range of 



5 



applications. For example, a deliverable content database can be configured with content that is 
appropriate for the particular application. Situational location parameters associated with the 
particular application are also variable, provided the installed methodology is utilized 
consistently. For example, world coordinates, GPS coordinates, regional coordinates, MAPSCO 
5 references, Application Address Book locations and directions, a user's caller id, a cell number 
in a cellular network, and like means used to describe a location can be used. Directional 
information of North, South, East, West, Northeast, Southeast, Northwest, Southwest, Up, 
Down, Left, Right, Straight, Back, and like methods used to describe a direction can be used. 
Further still, there are delivery constraints that can be set up for a system, or configured by a 
10 user, which provides flexibility in adapting to a variety of applications. 

[0021] It is another advantage of the present invention in providing deliverable content to a 
person, based on the situational location of the person. Content is pushed to a user's RDPS when 
it is most appropriate for the user to see the content. 

[0022] It is another advantage of the present invention in automatically recognizing a 
1 5 candidate delivery event of a RDPS and automatically determining a situational location of the 
RDPS. A user is not burdened with providing information on a query. The present invention 
automatically determines when content should be delivered and then automatically and 
proactively delivers it. Content is pushed to the user (of the RDPS). The user is not burdened 
with pulling content via a query. 

20 [0023] It is a further advantage of the present invention to deliver any type, variety, or 

combination of content. The content is fully configurable by an authorized administrator who 
may be a paying customer for the privilege of performing configurations. Upon configuration, 
the content is immediately and instantly activated for proactive delivery to any RDPS meeting 
the configured criteria. Content may be audio, video, graphical, textual, multimedia, 

25 intranet/internet web address(es) activated for transposable selection, image, or any combination 
thereof. 

[0024] It is another advantage in maintaining a history of delivered content at the RDPS with 
information that is useful for later browsing. Contained therein is information relevant to the 
delivered content. Additionally, provided is an invocable speed address enabling the user to 
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transpose to a web address, or perform a speed dial phone call, that is associated with the 
delivered content. 



[0025] Yet another advantage of the present invention is providing new and useful query 
functionality for querying the total number of known receiving data processing systems for a 
5 particular situational location, querying any content configured for delivery to a particular 
situational location with a comprehensive variety of query parameters, and querying up to a 
maximum threshold number of deliverable content instances for a particular location in a manner 
which automatically determines containing (ascending) locations, if necessary, until the specified 
number is met. 

10 [0026] Further features and advantages of the invention, as well as the structure and operation 
of various embodiments of the invention, are described in detail below with reference to the 
accompanying drawings. In the drawings, like reference numbers generally indicate identical, 
functionally similar, and/or structurally similar elements. The drawing in which an element first 
appears is indicated by the leftmost digit(s) in the corresponding reference number. 

15 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0027] The present invention will be described with reference to the accompanying drawings, 
wherein: 

[0028] Fig. 1 depicts a network illustration for discussing the various outdoor embodiments of 
20 the present invention; 

[0029] Fig. 2 depicts an aerial view of a city region useful for discussing aspects of the present 
invention; 

[0030] Fig. 3A depicts a locating by triangulation illustration for discussing a wireless, or 
cellular, embodiment of the present invention; 

25 [0031] Fig. 3B depicts a flowchart for describing a preferred embodiment of the candidate 
delivery event generation aspect relevant to a wireless, or cellular, embodiment of the present 
invention, in the context of positional attribute(s) being monitored by a SDPS; 
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[0032] Fig. 3C depicts a flowchart for describing a preferred embodiment of the candidate 
delivery event generation aspect relevant to a wireless, or cellular embodiment, of the present 
invention, in the context of positional attribute(s) being monitored by a RDPS; 

[0033] Fig. 4A depicts a locating by triangulation illustration for discussing a GPS, or satellite, 
5 embodiment of the present invention; 

[0034] Fig. 4B depicts a flowchart for describing a preferred embodiment of the candidate 
delivery event generation aspect relevant to a GPS, or satellite, embodiment of the present 
invention; 

[0035] Fig. 5 A depicts a locating by triangulation illustration for discussing an indoor wireless 
1 0 embodiment of the present invention; 

[0036] Fig. 5B depicts a flowchart for describing a preferred embodiment of the candidate 
delivery event generation aspect relevant to an indoor wireless embodiment of the present 
invention; 

[0037] Fig. 6 depicts a flowchart for describing a preferred embodiment of the candidate 
1 5 delivery event generation aspect relevant to a physically connected embodiment of the present 
invention; 

[0038] Fig. 7A depicts a preferred embodiment of a data record in the deliverable content 
database of the present invention; 

[0039] Fig. 7B depicts a preferred embodiment of a data record in the keyword data of the 
20 present invention; 

[0040] Fig. 8 depicts a preferred embodiment of a data record in the location hierarchy data of 
the present invention; 

[0041] Fig. 9A depicts a preferred embodiment of a data record in the registration data of the 
present invention; 

25 [0042] Fig. 9B depicts a preferred embodiment of a data record in the location history data of 
the present invention; 
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[0043] Fig. 9C depicts a preferred embodiment of a data record in the SDPS transmission 
history data of the present invention; 

[0044] Fig. 9D depicts a preferred embodiment of a data record in the RDPS transmission 
history data of the present invention; 

5 [0045] Fig. 10A depicts a preferred embodiment high level example componentization of a 
RDPS of the present invention when the RDPS generates the candidate delivery event; 

[0046] Fig. 10B depicts a preferred embodiment high level example componentization of a 
RDPS of the present invention when the SDPS generates the candidate delivery event; . 

[0047] Fig 10C depicts a block diagram of a data processing system useful for implementing 
10 RDPS aspects of the present invention, and SDPS aspects of the present invention; 

[0048] Fig. 1 1 depicts a flowchart for describing data processing system aspects relevant to a 
preferred embodiment of the RDPS of the present invention, in the context of candidate delivery 
event determination by the RDPS; 

[0049] Figs. 12A and 12B depict flowcharts for describing user event management processing 
1 5 aspects of a preferred embodiment of the RDPS of the present invention, in the context of 
candidate delivery event determination by the RDPS; 

[0050] Fig. 13 depicts a flowchart for describing system event management processing aspects 
of a preferred embodiment of the RDPS of the present invention, in the context of candidate 
delivery event determination by the RDPS; 

20 [0051] Fig. 14 depicts a flowchart for describing the content administration aspects of the 
present invention; 

[0052] Figs. 15 A, 15B, and 15C depict flowcharts for service event handling aspects of a 
preferred embodiment of the SDPS of the present invention, in the context of candidate delivery 
event determination by the RDPS; 

25 [0053] Fig. 16 depicts a flowchart for describing the content transmission aspects of the 
present invention; 
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[0054] Fig. 17 depicts a flowchart for describing data processing system aspects relevant to a 
preferred embodiment of the RDPS of the present invention, in the context of candidate delivery 
event determination not by the RDPS; 

[0055] Figs. 18A and 18B depict flowcharts for describing user event management processing 
5 aspects of a preferred embodiment of the RDPS of the present invention, in the context of 
candidate delivery event determination not by the RDPS; 

[0056] ' Fig. 19 depicts a flowchart for describing system event management . processing 
aspects of a preferred embodiment of the RDPS of the present invention, in the context of 
candidate delivery event determination not by the RDPS; and 

10 [0057] Figs. 20 A, 20B, and 20C depict flowcharts for service event handling aspects of a 

preferred embodiment of the SDPS of the present invention, in the context of candidate delivery 
event determination not by the RDPS. 

DETAILED DESCRIPTION OF THE INVENTION 
15 [0058] With reference now to detail of the drawings, the present invention is described. Obvious 

error handling is omitted from the flowcharts in order to focus on the key aspects of the present 

invention. 

[0059] Fig. 1 depicts a network illustration for discussing the various outdoor embodiments of 
20 the present invention. In one embodiment, a cellular network cluster 102 and cellular network 
cluster 104 are parts of a larger cellular network. Cellular network cluster 102 contains a 
controller 106 and a plurality of base stations, shown generally as base stations 108. Each base 
station covers a single cell of the cellular network cluster, and each base station 108 
communicates through a wireless connection with the controller 106 for call processing, as is 
25 well known in the art. Wireless devices communicate via the nearest base station (i.e. the cell 
the device currently resides in), for example base station 108b. Roaming functionality is 
provided when a wireless device roams from one cell to another so that a session is properly 
maintained with proper signal strength. Controller 106 acts like a telephony switch when a 
wireless device roams across cells, and it communicates with controller 1 10 via a wireless 
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connection so that a wireless device can also roam to other clusters over a larger geographical 
area. Controller 110 may be connected to a controller 1 12 in a cellular cluster through a physical 
connection, for example, copper wire, optical fiber, or the like. This enables cellular clusters to 
be great distances from each other. Controller 112 may in fact be connected with a physical 
5 connection to its base stations, shown generally as base stations 114. Base stations may 

communicate directly with the controller 112, for example/base station 1 14e. Base stations may 
communicate indirectly to the controller 112, for example base station 1 14a by way of base 
station 1 14d. It is well known in the art that many options exist for enabling interoperating 
communications between controllers and base stations for the purpose of managing a cellular 

10 network. A cellular network cluster 116 may be located in a different country. Base controller 
118 may communicate with controller 110 through a Public Service Telephone Network (PSTN) 
by way of a telephony switch 120, PSTN 122, and telephony switch 124, respectively. 
Telephony switch 120 and telephony switch 124 may be private or public. In one cellular 
network embodiment of the present invention, the SDPS executes at controllers, for example 

15 controller 110. The RDPS executes at a wireless device, for example mobile laptop computer 
126, wireless telephone 128, a personal digital assistant (PDA) 130, or the like. As the RDPS 
moves about, positional attributes are monitored for determining a situational location. The 
RDPS may be handheld, or installed in a moving vehicle. Locating a wireless device using 
wireless techniques such as Time Difference of Arrival (TDOA) and Angle Of Arrival (AO A) 

20 are well known in the art. The SDPS may also execute on a server computer accessible to 

controllers, for example server computer 132, provided an appropriate timely connection exists 
between cellular network controller(s) and the server computer 132. Wireless devices (i.e. 
RDPS) are known by a unique identifier, for example a caller id, device identifier, or like 
appropriate unique handle. 

25 [0060] In another embodiment of the present invention, GPS satellites such as satellite 134, 
satellite 136, and satellite 138 provide information, as is well known in the art, to GPS devices 
on earth for triangulation locating of the GPS device. In this embodiment, a RDPS has 
integrated GPS functionality so that the RDPS monitors its positional attribute(s). When the 
RDPS determines a candidate delivery event, it communicates parameters to the controller by 

30 way of the nearest base station. Thus, positional attribute information is provided by the RDPS 



to the SDPS. The RDPS is again known by a unique identifier, for example a caller id, device 
identifier, or like appropriate unique handle. 

[0061] In yet another embodiment of the present invention, a physically connected device, for 
example, telephone 140, computer 142, PDA 144, telephone 146, and fax machine 148, may be 
5 newly connected to a network. Each is a RDPS. Physical connections include copper wire, 
optical fiber, or the like. Devices are known by a unique identifier, for example a caller id, 
device identifier, physical or logical network address, or like appropriate unique handle. When 
the RDPS is detected for being newly located, the SDPS determines the candidate delivery event. 
The SDPS may execute at an Automatic Response Unit (ARU) 150, a telephony switch, for 

10 example telephony switch 120, a web server 152 (for example, connected through a gateway 
154), or a like data processing system that communicates with the RDPS. RDPS detection may 
be a result of the RDPS initiating a communication with the SDPS directly or indirectly. Thus, a 
user may connect his laptop to a hotel network, initiate a communication with the SDPS, and the 
SDPS determines that the user is in a different location than the previous communication. A 

15 local area network (LAN) 156 may contain a variety of connected devices, each an RDPS that 
later becomes connected to a local area network 158 at a different location, such as a PDA 160, a 
server computer 162, a printer 164, an internet protocol telephone 166, a computer 168, or the 
like. Hard copy presentation could be made to printer 164 and fax 148. Electronic content could 
be delivered to any RDPS. 

20 [0062J Current technology enables devices to communicate with each other, and other systems, 
through a variety of heterogeneous system and communication methods. Current technology 
allows executable processing to run on diverse devices and systems. Current technology allows 
communications between the devices and/or systems over a plethora of methodologies at close or 
long distance. Many technologies also exist for automatic locating of devices. It is well known 

25 how to have an interoperating communications system that comprises a plurality of individual 
systems communicating with each other with one or more protocols. As is further known in the 
art of developing software, executable processing of the present invention may be developed to 
run on a particular target data processing system in a particular manner, or customized at install 
time to execute on a particular data processing system in a particular manner. 
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[0063] Fig. 2 depicts an aerial view of a city region useful for discussing aspects of, and helps 
explain one application of, the present invention. A Starbucks coffee shop 202 (Starbucks is a 
trademark of Starbucks corporation) is located in an area frequented by handheld wireless device 
(i.e. RDPS) user pedestrians, for example pedestrian 204, and wireless device (i.e. RDPS) 
5 equipped vehicles, for example automobile 206 and automobile 208. Starbucks is a paying 

customer to the owner of the present invention wherein content can be configured for advertising 
to potential customers of Starbucks. An authorized and authenticated Starbucks representative 
uses the present invention, for example by way of an internet connected web browser, to 
configure the deliverable content. The representative also configures situational location 

10 information that is to be matched to situational locations of a RDPS of mobile customers. Upon 
configuration completion, the content is immediately activated for proactive delivery. The 
present invention will automatically deliver the Starbucks configured content to any RDPS 
according to the representative's configurations, for example, when pedestrian 204 becomes in a 
specified proximity to the Starbucks location, encounters a specific location, travels in a manner 

15 which provides predictive information, heads in a specified direction at, to, or from a location, or 
the like, using positional attribute(s). Likewise, automobile 206 will receive the content 
according to configurations, for example, when making a left hand turn (i.e. changing direction 
at a location area) onto the street bearing Starbucks 1 address. Likewise, automobile 208 will 
receive the content according to configurations, for example, when encountering a location in 

20 proximity to the Starbucks location while heading North. One example of the content may be a 
textual message such as "Starbucks has a 60% off sale just ahead at 314 Main Street with free 
no-spill coffee mugs! ! ! Other examples may include a graphical map showing where the 
Starbucks establishment is in relation to showing where the* RDPS is currently located and 
headed. 

25 [0064] Fig. 3 A depicts a locating by triangulation illustration for discussing a wireless, or 

cellular, embodiment of the present invention. A RDPS 302 is located through triangulation, as 
is well known in the art. At least three base towers, for example, base tower 108b, base tower 
108d, and base tower 108f, are necessary for locating the RDPS. A fourth base tower would be 
used if altitude was configured for use by the present invention. There are cases where only two 

30 base towers are necessary given routes of travel are limited and known, for example, in spread 
out roadways or limited configured locations. 

13 



[0065] Fig. 3B depicts a flowchart for describing a preferred embodiment of the candidate 
delivery event generation aspect relevant to a wireless, or cellular, embodiment of the present 
invention, in the context of positional attribute(s) being monitored by a SDPS. Processing begins 
at block 310 and continues to block 312 where base stations able to communicate to any degree 
5 with a RDPS continue reporting to their controller the RDPS signal strength with an RDPS 
identifier (i.e. a unique handle) and Time Difference of Arrival (TDOA) information, or 
alternatively, Angle of Arrival (AO A) information, depending on the embodiment. When the 
RDPS turns on, it registers itself. The RDPS can pick signals from base stations. In one 
embodiment, the RDPS monitors a paging channel, called a forward channel. There can be 
10 multiple forward channels. A forward channel is the transmission frequency from the base tower 
to the RDPS. Either the RDPS provides heartbeat for base stations, or the base stations provide 
heartbeats for a response from the RDPS. Communication from the RDPS to the base tower is 
on what is called the reverse channel. Forward channels and reverse channel are used to perform 
call setup for a created session channel. 

15 [0066] TDOA is conventionally calculated from the time it takes for a communication to occur 
from the RDPS back to the RDPS via the base tower, or alternatively, from a base tower back to 
that base tower via the RDPS. AO A is conventionally performed through calculations of the 
angle by which a signal from the RDPS encounters the base tower antenna. Simple triangle 
geometry is then used to calculate a location. The AOA antenna is typically of a phased array 

20 type. 

[0067] The controller at block 314 may communicate with other controllers when base stations 
in other cellular clusters are picking up a signal, for example, when the RDPS roams. In any 
case, at block 314, the controller(s) determines the strongest signal base stations needed for 
locating the RDPS, at block 314. The strongest 3 (or 2 or 4 as discussed above) are used. 

25 Thereafter, block 316 accesses base station location information for base stations determined at 
block 314. The base station provides location anchors used to (relatively) determine the location 
of the RDPS. Then, block 3 1 8 uses the TDOA, or AOA, information together with known base 
station locations to calculate the RDPS location. Blocks 310 through 318 are well known to 
those skilled in art. Thereafter, block 320 accesses historical RDPS location information, and 

30 block 322 performs housekeeping by pruning location history data for the RDPS by time, 
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number of entries, or other criteria. Block 324 then determines a direction of the RDPS based on 
previous location information. Block 324 may perform Artificial Intelligence (AI) to determine 
where the traveler may be going by consulting many or all of the location history data. Block 
324 may also consider when and/or where a candidate delivery event (CADE) was generated for 
5 a direction change in order to cause certain flow from block 330. Block 326 calculates how 
much (e.g. distance) the RDPS has moved since the previous location that caused a candidate 
delivery event (CADE) generation for the RDPS (event generated Y/N field in location history 
data). Thereafter, block 328 compares the movement since the last CADE generation, and if the 
distance exceeds a movement tolerance, then block 332 posts (generates) a CADE to a present 
10 invention service handling RDPS situational location changes. The movement tolerance may be 
a system wide setting for all RDPS devices, particular to a type of RDPS, or specific for an 
RDPS. 

[0068] If, at block 328, movement did not exceed the tolerance, then block 330 checks for a 
direction change as determined at block 324. If, at block 330, the direction did change, then a 

15 CADE is generated at block 332. If, at block 330, the direction of the RDPS did not change, 
then block 334 appends an appropriate entry to the location history data (see Fig. 9B). Block 
332 also flows to block 334. Blocks 324 through 330 determine if a CADE is to be generated, 
and if so, a CADE is generated at block 332. Blocks 324 through 330 determine part, or all, (i.e. 
a subset) of the situational location, depending on the installation. Fig. 3B processing is 

20 continuous for every RDPS in the wireless network 7 days a week, 24 hours a day. 

[0069] Fig. 3C depicts a flowchart for describing a preferred embodiment of the candidate 
delivery event generation aspect relevant to a wireless, or cellular, embodiment, of the present 
invention, in the context of positional attribute(s) being monitored by a RDPS. Figure 3B 
demonstrated the CADE and part, or all, of the situational location being determined by a SDPS 

25 service. Figure 3C demonstrates the CADE, and part, or all, of the situational location being 
determined by the RDPS itself, and then communicated to the SDPS for any further situational 
location determination and applicable content delivery. Communications between the base 
stations and RDPS is similar to above except the RDPS receives information for performing 
calculations and related processing. Processing begins at block 350 and continues to block 352 

30 where the RDPS continues receiving pulse reporting from base stations. Block 354 determines 

15 



the strongest 3 signals (or 2 or 4). Thereafter, block 356 parses base station location information 
from the pulse messages that are received by the RDPS. Block 358 communicates with base 
stations to perform TDOA calculations. The time it takes for a communication to occur from the 
RDPS back to the RDPS, or alternatively, from a base tower back to that base tower is used. 
5 Block 358 uses the TDOA information with the known base station information to determine the 
RDPS location. Blocks 350 through 358 are well known to those skilled in art. 

[0070] Thereafter, block 360 accesses historical RDPS location information, and block 362 
performs housekeeping by pruning the location history data for the RDPS by time, number of 
entries, or other criteria. Block 364 then determines a direction of the RDPS based on previous 

10 location information. Block 364 may perform Artificial Intelligence (AI) to determine where the 
traveler may be going by consulting much or all of the location history data. Block 364 may also 
consider when and/or where a candidate delivery event (CADE) was generated for a direction 
change in order to cause certain flow from block 370. Block 366 calculates how much (e.g. 
distance) the RDPS has moved since the previous location that caused a candidate delivery event 

1 5 (CADE) generation for the RDPS (event generated Y/N field in location history data). 
Thereafter, block 368 compares the movement since the last CADE generation and if the 
distance exceeds a movement tolerance, then block 372 posts (generates) a CADE to the present 
invention system event manager of the RDPS. The movement tolerance may be a system or user 
configured setting. 

20 [0071] If, at block 368, movement did not exceed the tolerance, then block 370 checks for a 
direction change as determined at block 364. If, at block 370, the direction did change, then a 
CADE is generated to the system event manager at block 372. If, at block 370, the direction of 
the RDPS did not change, then block 374 appends an appropriate entry to the location history 
data (see Fig. 9B). Block 372 also flows to block 374. Blocks 364 through 370 determine if a 

25 CADE is to generated, and if so, a CADE is generated at block 332. Blocks 364 through 370 
determine part, or all, (i.e. a subset) of the situational location, depending on the installation. 
Fig. 3C processing is continuous for the RDPS as long as the RDPS is enabled. 

[0072] Fig. 4A depicts a locating by triangulation illustration for discussing a GPS, or satellite, 
embodiment of the present invention. A RDPS 402 is located through GPS triangulation as is 
30 well known in the art. At least three satellites, for example, satellite 134, satellite 136, and 
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satellite 138, are necessary for locating the RDPS. A fourth satellite would be used if altitude 
was configured for use by the present invention. 

[0073] Fig. 4B depicts a flowchart for describing a preferred embodiment of the candidate 
delivery event generation aspect relevant to a GPS, or satellite, embodiment of the present 
5 invention. GPS location processing begins at block 410 and continues to block 412 where the 
RDPS initializes for using a system management interface. The system event manager may be a 
software interrupt, hardware interrupt, queue, or other event handling entity. Block 414 
performs the conventional locating of the GPS enabled RDPS, and block 416 posts (generates) a 
CADE to the RDPS system event manager. Block 414 may be an implicit wait for pulses from 

10 satellites, or an event driven mechanism when GPS satellite pulses are received for synchronized 
collection. Block 414 processing is well known in the art. Block 416 may post the event 
information to other processes depending on the RDPS features using such information. 
Thereafter, the GPS location information is used at block 418 as applicable to the particular 
RDPS embodiment, for example showing the RDPS location on a graphical map. GPS location 

15 processing is continuous for the RDPS as long as the RDPS is enabled. 

[0074] The CADE in this example is a result of a simple location change. Any further 
situational location determination task remains for the system event manager. An alternative 
embodiment to block 414 would further include processing of Fig. 3C blocks 360 through 370 to 
determine part, or all, (i.e. a subset) of the situational location so that a CADE is generated at 
20 block 416 only if the situation warrants it. 

[0075] Fig. 5 A depicts a locating by triangulation illustration for discussing an indoor wireless 
embodiment of the present invention. There may be communication/transmission issues when 
an RDPS is taken indoors. There are also unique applications of the present invention for indoor 
use. Shown is a top view of an indoor floor plan 502. Antenna stations 504 (shown generally as 
25 504) are strategically placed over the area so that an RDPS, for example, an RDPS equipped 
shopping cart 506, can be located. The conventional triangulation techniques again apply. At 
least three antenna stations, for example, station 504f, station 504h, and station 504i are used to 
locate the RDPS equipped shopping cart 506. In floor plan embodiments where aisles delimit 
travel, only two antenna stations may be necessary, for example at either end of the particular 



17 



aisle. While most stations 504 may receive signals from the RDPS, only the strongest stations 
are used. 



[0076] In this example embodiment of using the present invention, a shopper with a grocery 
cart receives content at the RDPS as the shopping cart is navigated throughout the store. Special 
5 deal, sales, or other promotional content is pushed automatically by the present invention to the 
RDPS of the shopping cart, at appropriate situational locations of the shopping cart. A store 
representative will manage what content to deliver through -convenient configuration of the 
present invention. The store will provide RDPS equipped shopping carts, or may provide 
handheld RDPS devices, so that shoppers will get the most of their experience by automatically 
10 receiving content that is appropriate to the shopper's situational location in the store. 

[0077] Fig. 5B depicts a flowchart for describing a preferred embodiment of the candidate 
delivery event generation aspect relevant to an indoor wireless embodiment of the present 
invention. In one embodiment, indoor location technology of Pinpoint corporation (Pinpoint is a 
trademark of Pinpoint Corporation) is utilized to locate any RDPS that moves about the indoor 

1 5 location. The Pinpoint corporation methodology begins at block 5 1 0 and continues to block 512. 
A cell controller drives antenna stations to emit a broadcast signal from every station. Any 
RDPS within range (i.e. indoors), will phase modulate its unique identifier onto a return signal it 
transmits, at block 514. Stations at block 516 receive the transmission and strength of signal. 
The cell controller that drives stations sorts out and selects the strongest 3 signals. The cell 

20 controller, at block 5 1 8, also extracts the RDPS unique identifier from the return signal, and 
% TDOA (or AOA if phase array antennas are used) is used to calculate distances from the stations 
receiving the strongest signals from the RDPS at block 520. The locations of the controller 
selected stations are registered in an overlay map in an appropriate coordinate system, landmark 
system, or grid of cells. Block 522 locates the RDPS using the overlay map, locations of the 3 

25 selected stations, and the calculated distances triangulated from the selected stations. Processing 
through block 522 has located the RDPS with known Pinpoint corporation technology. 
Thereafter, a block 524 can perform a CADE generation to a SDPS service of the present 
invention. Processing continues with repeated broadcast at block 512 and subsequent processing 
for every RDPS. 
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[0078] The CADE in this example is a result of a simple location change. Any further 
situational location determination task remains for the SDPS event handler. An alternative 
embodiment to block 524 would further include processing of Fig. 3B blocks 320 through 330 to 
determine part, or all, (i.e. a subset) of the situational location so that a CADE is generated at 
5 block 524 only if the situation warrants it. 

[0079] Fig. 6 depicts a flowchart for describing a preferred embodiment of the candidate 
delivery event generation aspect relevant to a physically connected embodiment of the present 
invention. A RDPS may be newly located and physically connected, whereby communications 
between the RDPS and SDPS is over a physical connection. With reference now to Fig. 1, when 

10 a RDPS, for example internet protocol telephone 166, is moved from LAN 156 to a LAN 158 in 
a different location, the present invention detects the location change when the RDPS initiates a 
communication to the SDPS. With reference back to Fig. 6, relevant processing according to the 
present invention begins at block 602 and continues to block 604 where an RDPS device is 
physically connected to a network. Thereafter, the RDPS accesses a SDPS incorporating the 

15 present invention, at block 606. Then, at block 608, the SDPS accesses historical RDPS location 
information (i.e. the previous location history data record 900 - see Fig. 9B location history data 
discussion below), and block 610 performs housekeeping by pruning the location history data 
maintained for the RDPS by time, number of entries, or other criteria. Block 608 may perform 
Artificial Intelligence (AI) to determine where the traveler may be going (e.g. using direction 

20 based on previous locations) by consulting much or all of the location history data. Thereafter, 
SDPS processing, at block 612, compares the current network address with the previous network 
address. If they are identical, then SDPS processing continues to block 616. If they are 
different, then the SDPS generates a CADE to the event handling service of the SDPS at block 
614. Thereafter, SDPS processing continues to block 616. Block 616 appends an entry to the 

25 location history data for the RDPS, and SDPS processing ends at block 618. Block 612 may 
compare to other location history data information, depending on any AI of block 608. 

[0080] Fig. 7A depicts a preferred embodiment of a data record in the deliverable content 
database of the present invention. A deliverable content database record 700 includes fields 702 
through 724 as shown. Rec id field 702 is a unique identifier to the record in the database. Rec 
30 id field 702 is system generated, for example, using an Oracle unique sequence number function 
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(Oracle is a trademark of Oracle corporation) upon inserting the record (i.e. database row) into 
the deliverable content database (i.e. database table). The rec id field 702 is used in the 
transmission history data to correlate transmitted content, enables detection of redundant 
delivery, and enables later RDPS retrieval of content when only a content delivery indicator is 
5 transmitted to an RDPS. Location field 704 contains a positional attribute of location 

information for which the associated content will be delivered. Depending on the installation, 
the location field contains a cellular network cell identifier, truncated precision geocentric 
coordinates, truncated precision geodetic coordinates, truncated three dimensional space 
coordinates, area described by GPS coordinates (e.g. four corners of a grid rectangle), overlay 

10 grid region identifier or coordinates, GPS coordinates with truncated precision, altitude, 
MAPSCO reference, telephone number (e.g. caller id), physical or logical network address 
(including a wildcard (e.g. ip addresses 145.32.*.*)), particular application address, or a like 
location. Truncated precision allows specifying a broader scope, for example, latitude/longitude 
in degrees, minutes, seconds, etc., depends on how the number is truncated. Zooming in implies 

15 more precision. Zooming out implies less precision. Combinations of these positional attributes 
may also designate a location. Depending on the installation, the positional attribute direction 
field 706 contains a direction such as North, South, East, West, or Southwest, Southeast, 
Northwest, Northeast, or Left, Right, Straight, Back, or Up, Down, or the like. A value of null 
may also be present when a direction is inappropriate, for example in one embodiment of Fig. 6. 

20 Time criteria field 708 contains a time window(s), or time interval(s), for which the associated 
deliverable content is valid for delivery. Preferably, time points of time criteria are entered in 
"YYYYMMDDHHMMSS" format. Content type field 710 describes the type of content field 
712. Content types include, and are not limited to, web address, audio, image, multimedia, text, 
and video. The content field 712 contains the deliverable content, or a reference such as a 

25 filename, pointer, or the like, to the content. Short Text info field 714 allows configuration of a 
short textual message to be delivered to the RDPS and maintained in the RDPS transmission 
history data, for example, a business address. Speed reference info 716 is a web address or 
phone number that is delivered to the RDPS with the content, and is also maintained in the RDPS 
transmission history for convenient invocation. Thus, the user may browse the history, and 

30 invoke the speed reference for automatic telephone call dialing from the RDPS, or for automatic 
web address transposition in a launched web browser, upon a simple user selection of the speed 
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reference from the history. Depending on the installation, delivery activation setting(s) field 718 
will contain a bit mask, or the like, for the RDPS state which establishes delivery. For example, 
the bit mask will contain a settable bit for: 

• Deliver on RDPS registration 
5 • Deliver on RDPS termination 

• Deliver only when RDPS requests 

• Deliver always (used for emergency use ~ see Amber- Alert discussion above) 

• Deliver for situational location change 

• 3 or more bits reserved for future use 

10 [0081] Authorization id field 720 contains a handle to the user who configured the database 
record 700, for example, a password, user identifier, or the like (may be encrypted). Content 
links field 722 contains a YES/NO flag for whether there are multiple content fields associated 
with the database record 700. A separate database entity (not shown), for example a database 
table, can be maintained with 3 fields: one containing a matching rec id field 702 to associate the 

15 content to the deliverable content database record 700, one for the content type (like content type 
field 710), and one for the content (like content field 712). There may be a plurality of database 
records in the separate database entity that are associated with the deliverable content database 
record 700. The value in the rec id field 702 will be used to join all content items. 

[0082] Applications specific data fields 724 are available for the SDPS being an integrated 
20 solution with some other service. Location field 704, direction field 706, time criteria field 708, 
and delivery activation setting(s) field 718 together form the situational location information 
associated with the content which establishes a delivery. 

[0083] Fig. 7B depicts a preferred embodiment of a data record in the keyword data of the 
present invention. A keyword data record 750 is joined to a deliverable content database record 
25 700 through a matching rec id field 752. Keywords field 754 contains one or more comma 
separated text strings used to associate criteria to the deliverable content database record 700. 
Phrases containing blank separated words are enclosed in quote marks. In one embodiment of 
the present invention, a RDPS user specifies interests that are matched to the keywords field 754. 
Only the user's interests, along with the RDPS situational location, will cause delivery of 
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associated content. An alternative embodiment for maintaining keyword data will associate a 
plurality of keyword data records 750 to a deliverable content database record 700, each 
containing a singular keyword, or phrase, in keywords field 754. Fields 704, 706, 708, 718, and 
754 are system delivery constraints of the present invention. 

5 [0084] Fig. 8 depicts a preferred embodiment of a data record in the location hierarchy data of 
the present invention. A location hierarchy data record 800 has fields as shown. Rec id field 802 
is a unique identifier to the record. Rec id field 802 is system generated, for example, using an 
Oracle unique sequence number function upon inserting the record (i.e. database row). Location 
field 804 is a location of the nature as described for location field 704. Ascending location field 

10 706 is a value found in rec id field 802 of another location hierarchy data record 800. If used, the 
configuration of this table must be performed carefully so as to affect its use appropriately. 
Semantically, field 806 must be an ascending location to field 804. For example, Texas is 
ascending to Denton County, and Denton County is ascending to Flower Mound. Similarly, a set 
of MAPSCO grid numbers, that surround a MAPSCO reference grid D of map 691, are 

1 5 ascending to MAPSCO reference grid D of map 691 . Ascending implies zooming out to cover 
more surrounding area. Location hierarchy data is searched in the following manner: 

• For content by candidate delivery events, content is retrieved by the location, 
and any locations descending to that location (i.e. zoom in) 

• For situational location queries, content is optionally retrieved by the location 
20 and descending locations, and optionally, ascending locations as necessary (i.e. 

zoom out) according to parameters (discussed below) 

[0085] Fig. 9A depicts a preferred embodiment of a data record in the registration data of the 
present invention. A registration data record 900 is maintained by the SDPS and includes fields 
as shown. Device id field 902 is a unique handle to an RDPS. Depending on the installation, 
25 device id field 902 may be a telephone #, physical or logical address, or some other unique 
handle to the RDPS. Communications bind information field 904 is a record describing the 
communications session between the RDPS and SDPS, as is well known in the art. In some 
embodiments, field 904 contains capability information sent from the RDPS so that only the 
appropriate content is delivered, for example acceptable types of, or acceptable amounts (size) 
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of, content. Interests field 906 contains one or more comma separated user configured text 
strings used to match to the keywords field 754. If used, only the user's interests, along with the 
RDPS situational location, will cause proactive delivery of associated content. Filter criteria 
field 908 is identical in nature to interests field 906 and keywords field 754 except the criteria is 
5 for exclusion. If used, filter criteria field 908 is also compared with keywords field 754. Thus, 
the RDPS user can configure interests for inclusion through field 906, or criteria for exclusion 
through field 908. Movement tolerance field 910 defines the minimal amount of movement 
since the last delivery content retrieval attempt that determines to perform another retrieval. 
Movement tolerance field 910 is optional depending on the installation. The movement 

10 tolerance may be a system wide setting enforced by the SDPS, associated to a class of RDPS 
devices, or individualized by the user or system. Field 910-may not be present because the 
movement tolerance is maintained by the RDPS, or is not applicable to the installation (e.g. 
RDPS physically connected, or located by caller id). The movement tolerance depends on the 
installed use of location field 704. For example, in a coordinate system, a distance may be 

15 configured. In an overlay map, region, or cell change, a number of regions or cells from a 
previous location may be configured. Fields 906 and 908 are user configured delivery 
constraints of the present invention. Registration data record 900 presence enables delivery to 
the associated RDPS, otherwise the RDPS is not an eligible receiver. Obvious error handling at 
the SDPS ignores all requests that are not from a RDPS with a device id in the registration data 

20 (except for registration types of requests ( i.e. events)). 

[0086] Fig. 9B depicts a preferred embodiment of a data record in the location history data of 
the present invention. A location history data record 920 is maintained for the travels of a 
RDPS, and includes fields as shown. Device id field 922 is. identical in nature to device id field 
902. Location field 924 is identical in nature to location field 704. Direction field 926 is 
25 identical in nature to direction field 706. Event posted field 928 is a YES/NO flag for whether or 
not this location history data record 920 is associated with generating a CADE. Date/time stamp 
field 930 is the time that the RDPS was detected at the associated location and specified direction 
of fields 924 and 926. Direction field 926 is optional depending on the installation, as discussed 
above. 
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[0087] Fig. 9C depicts a preferred embodiment of a data record in the SDPS transmission 
history data of the present invention. A transmission history data record 940 is maintained at the 
SDPS for all content that is transmitted to the RDPS, and includes fields as shown. Device id 
field 942 is identical in nature to device id field 902. Location field 944 is identical in nature to 
5 location field 704. Direction field 946 is identical in nature to direction field 706. Rec id field 
948 contains a copy of rec id field 702 for content that was transmitted to the RDPS of field 942. 
Indicator sent field 950 is a YES/NO flag for whether or not the content was actually transmitted, 
or a content delivery indicator for the content was transmitted. Date/time stamp field 952 is the 
time that content described by field 948 was transmitted to the RDPS. Direction field 946 is 
10 optional depending on the installation, as discussed above. 

[0088] Fig. 9D depicts a preferred embodiment of a data record in the RDPS transmission 
history data of the present invention. A transmission history data record 970 is maintained at the 
RDPS for all content that is received by the RDPS, and includes fields as shown. Date/time 
stamp field 972 is the time that content described by rec id field 976 was received by the RDPS. 

1 5 Indicator sent field 974 is a YES/NO flag for whether or not the content was actually received, or 
an indicator for the content was received. Rec id field 976xontains a copy of rec id field 702 for 
content that was received by the RDPS. Speed reference information field 978 contains a phone 
number for automatic dialing, a web page reference for automatic transposition, or both. Speed 
reference information field 978 is obtained by the RDPS from field 716. Short text field 980 is 

20 obtained by the RDPS from 714. Location field 982 is identical in nature to field 704. Direction 
field 984 is identical in nature to field 706. Field 982 and 984 may not be used if this 
information is maintained at the SDPS. Fields 982 and 984 are preferably used when the RDPS 
handles CADE generation, or if the SDPS additionally transmits the information with the 
content. Direction field 984 is optional depending on the installation, as discussed above. 

25 [0089] Fig. 10A depicts a preferred embodiment high level example componentization of a 
RDPS of the present invention when the RDPS generates the candidate delivery event. An 
RDPS 1000 includes system manager 1002, location management system 1004, system event 
management 1006, user event management 1008, user interface management 1010, and 
communications interface 1012. System manager 1002 is the operating system environment of 

30 the RDPS 1000. Location management system 1004 provides means for locating the RDPS 
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1000, for example GPS functionality. System event management 1006 provides an interface to 
system event processing relevant to the present invention that is not directly caused by a user. 
User event management 1008 provides an interface to event processing relevant to the present 
invention that is directly caused by a user, for example when the user uses the RDPS user 
5 interface. User interface management 1010 is the user interface system environment of the 
RDPS 1000, for example, a variety of Microsoft Windows (Microsoft and Windows are 
trademarks of Microsoft corporation), a wireless phone interface, or some other user interface 
system. Communications interface 1012 provides the interface between the RDPS 1000 and the 
SDPS. 

[0090] Fig. 10B depicts a preferred embodiment high level example componentization of a 
RDPS of the present invention when the SDPS generates the candidate delivery event. An RDPS 
1020 includes a system manager 1022, system event management 1026, user event management 
1028, user interface management 1030, and communications interface 1032. System manager 
1022 is the operating system environment of the RDPS 1020. System event management 1026 
provides an interface to system event processing relevant to the present invention that is not 
directly caused by a user. User event management 1028 provides an interface to event 
processing relevant to the present invention that is directly caused by a user, for example when 
the user uses the RDPS user interface. User interface management 1030 is the user interface 
system environment of the RDPS 1020, for example, a variety of Microsoft Windows (Microsoft 
and Windows are trademarks of Microsoft corporation), a wireless phone interface, or some 
other user interface system. Communications interface 1032 provides the interface between the 
RDPS 1020 and the SDPS. RDPS 1000 and RDPS 1020 may further include a local cache with 
a cache management component that facilitates cacheing the deliverable content database and 
associated data at the RDPS for efficient access. 

25 [0091] Fig 10C depicts a block diagram of a data processing system useful for implementing 
RDPS aspects of the present invention, and SDPS aspects of the present invention. A data 
processing system 1050 according to the present invention includes at least one processor 1052 
coupled to a bus 1054. The data processing system 1050 also includes main memory 1056, for 
example, random access memory (RAM). Optionally, the data processing system 1050 may 

30 include secondary storage devices 1058 such as a hard disk drive 1060, and/or removable storage 
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device 1062 such as a compact disk, floppy diskette, or the like, also connected to bus 1054. In 
one embodiment, secondary storage devices could be remote to the data processing system 1050 
and coupled through an appropriate communications interface. 

[0092] The data processing system 1050 may also include a display device interface 1064 for 
5 driving a connected display device (not shown). The data processing system 1050 may further 
include one or more input peripheral interface(s) 1066 to input devices such as a keyboard, 
telephone keypad, Personal Digital Assistant (PDA) writing implements, mouse, voice interface, 
or the like. User input (i.e. user events) to the data processing system are inputs accepted by the 
input peripheral interface(s) 1066. The data processing system 1050 may still further include 
10 one or more output peripheral interface(s) 1068 to output devices such as a printer, facsimile 
device, or the like. 

[0093] Data processing system 1050 will include a communications interface 1070 for 
communicating to an other data processing system 1072 via analog signal waves, digital signal 
waves, infrared proximity, copper wire, optical fiber, or the like. Other data processing system 
15 1072 is an RDPS when data processing system 1050 is an SDPS. Other processing system 1072 
is an SDPS when data processing system 1050 is an RDPS. In any case, the RDPS and SDPS 
are said to be interoperating when communicating. Thus, the RDPS and SDPS form an 
interoperating communications system between which data may be communicated. 

[0094] Data processing system programs (also called control logic) may be completely 
20 inherent in the processor 1052 being a customized semiconductor, or may be stored in main 

memory 1056 for execution by processor 1052 as the result of a read-only memory (ROM) load 
(not shown), or may be loaded from a secondary storage device into main memory 1056 for 
execution by processor 1052. Such programs, when executed, enable the data processing system 
1050 to perform features of the present invention as discussed herein. Accordingly, such data 
25 processing system programs represent controllers of the data processing system. 

[0095] In one embodiment, the invention is directed to a control logic program product 
comprising a processor 1052 readable medium having control logic (software) stored therein. 
The control logic, when executed by processor 1052, causes the processor 1052 to perform 
functions of the invention as described herein. 
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[0096] In another embodiment, the invention is implemented primarily in hardware, for 
example, using a prefabricated component state machine (or multiple state machines) in a 
semiconductor element such as processor 1052. 

[0097] Those skilled in the art will appreciate various modifications to the data processing 
5 system 1050 without departing from the spirit and scope of the invention. Data processing 

system 1050, as discussed, is representative of a RDPS of the present invention. Data processing 
system 1050, as discussed, is representative of a SDPS of the present invention. 

RECEIVING DATA PROCESSING SYSTEM 
CANDIDATE DELIVERY EVENT GENERATION EMBODIMENT 

10 [0098] Fig. 1 1 depicts a flowchart for describing data processing system aspects relevant to a 
preferred embodiment of the RDPS of the present invention, in the context of candidate delivery 
event generation by the RDPS. When the RDPS is enabled, for example, by a power switch, 
' system manager processing begins at block 1 102 and continues to block 1 104 where the system 
appropriately initializes, for example to default interfaces. Processing continues to block 1 106 

1 5 where the location management system is initialized as is appropriate for the particular RDPS, 
and then on to block 1 108 where a movement tolerance is defaulted, depending on the RDPS 
installation, and depending on what it was during the last power-on. The movement tolerance 
may be user configurable or system set, and is therefore either a system delivery constraint, or 
user configured delivery constraint. Thereafter, block 1110 defaults situational location 

20 information to the most recent setting for a CADE from last power-on, or system just started if 
this is the first power-on, and block 1112 waits for a user event or system event. User interface 
management is coupled with the system manager to enable a user to the RDPS. Upon detection 
of an event, block 1112 flows to block 1 1 14 for any user event management processing. Should 
block 1114 processing return, block 1116 performs any system event management processing. 

25 Should processing of block 1116 return, block 1118 handles the event appropriately as is 
relevant for other events of the RDPS, for example, user interface control of little interest to 
discussion of the present invention. Thereafter, block 1118 flows to block 1 1 12 for processing 
as described. 

[0099] An alternate embodiment of Fig. 1 1 will implement a multithreaded system wherein 
30 events are handled asynchronously as they occur. 
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[0100] Figs. 12A and 12B depict flowcharts for describing user event management processing 
aspects of a preferred embodiment of the RDPS of the present invention, in the context of 
candidate delivery event generation by the RDPS. User event management begins at block 1202 
and continues to block 1204. If block 1204 determines that the user event is powering the RDPS 
5 off, then block 1206 communicates with the SDPS to remove (if any) its RDPS data record 900 
from the registration data, block 1208 terminates any communication session gracefully (if 
required) depending on the RDPS, block 1210 saves settings, for example, the movement 
tolerance and delivery setting for the next power on, and RDPS processing stops at block 1211. 

[0101] If block 1204 determines the RDPS was not turned off, then processing continues to 
10 block 1212. If block 1212 determines that the user selected to enable communications with the 
SDPS, then block 1214 establishes communications with the SDPS (if not already established), 
and block 1216 consults the current delivery setting. In one embodiment, block 1214 through 
1220 may be processed just as the result of a wireless device being powered on. If block 1216 
determines that the content delivery setting for receiving situational location dependent content is 
15 enabled, then block 1218 communicates with the SDPS for inserting a registry data record 900 
into the registry data. Thereafter, block 1220 sets a RDPS user interface indicator showing that 
communications to the SDPS is enabled, and processing returns to block 1112 of Figure 1 1 by 
way of off page connector 1 1000. If block 1216 determines the delivery setting is not enabled, 
then processing continues to block 1220. 

20 [0102] If block 1212 determines that the user did not select to enable communications to the 
SDPS, then processing continues to block 1222. If block 1222 determines that the user selected 
to disable SDPS communications, then block 1224 communicates with the SDPS to remove its 
registry data record 900 from registry data, block 1226 terminates the communications session 
gracefully (if required) depending on the RDPS embodiment, block 1228 sets the 

25 communications to SDPS user interface indicator to disabled, and processing continues back to 
block 1112. In one embodiment, block 1224 through 1228 may be processed just as the result of 
a wireless device being powered off. 

[0103] If block 1222 determines the user did not select to disable communications to the 
SDPS, then processing continues to block 1230. If block 1230 determines that the user selected 
30 to modify the RDPS content delivery setting, then the user modifies the setting at block 1232, the 
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delivery setting is set accordingly at block 1234. Preferably, blocks 1230/1232 allow a user to 
toggle the content delivery setting. No content will be delivered when this setting is disabled. 
Being registered with the SDPS constitutes being eligible for delivery. Alternative embodiments 
won't have such a feature. The content delivery setting is a user configured delivery constraint. 
5 Block 1234 also sets and an indicator in the user interface for displaying that setting, and block 
1236 communicates with the SDPS to insert or remove its registry data record 900 should the 
setting be different than previous. Of course, appropriate error handling is performed by block 
1236 if there is no communications enabled. Thereafter, processing continues to block 1 1 12. 

[0104] If block 1230 determines that the user did not select to modify the content delivery 
10 setting, then processing continues to block 1238. If block 1238 determines that the user selected 
to modify the movement tolerance, then the user modifies a validated movement tolerance at 
block 1240, the movement tolerance is set at block 1242, and processing continues back to block 
1112. 

[0105] If block 1238 determines that the user did not select to modify the movement tolerance, 
15 then processing continues to block 1244. If block 1244 determines that the user selected a 

content delivery indicator, as maintained in a transmission history data record 970 for deliverable 
content from the SDPS, then block 1246 communicates with the SDPS using the rec id field 976. 
In one embodiment, the user peruses the transmission history data in response to receiving a 
content delivery indicator from the SDPS. In another embodiment, correlation is maintained 
20 between individual user interface indicators to their associated transmission history data record 
970 for allowing the user to simply select the indicator in the user interface for communicating 
with the SDPS to deliver the associated content. Providing a visual and/or audible presentation 
of the indicator is well known in the art, and may be implemented with a variety of methods. 
Block 1246 makes the request for content to the SDPS with the rec id 976. Thereafter, via a 
25 received system event, blocks 1318 through 1326 handle receipt, delivery, and RDPS user 

interface presentation of the content in a manner appropriate to the content type from the SDPS. 
Processing continues from block 1246 back to block 1112. 

[0106] If block 1244 determines that the user did not select an indicator of deliverable content, 
then processing continues to block 1250 by way of off page connector 12000. If block 1250 
30 determines that the user selected to configure interests or filters, then block 1252 interfaces with 
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the user to configure interests or filters which are saved locally at block 1254, and processing 
continues back to block 1 1 12 by way of off page connector 1 1000. Any configured interests and 
filters are communicated to the SDPS at blocks 1218 and 1236 as part of registration. Interests 
field 906 and filter criteria field 908 are set with data configured at block 1252. The RDPS must 
5 de-register and re-register with new settings. In an alternative embodiment, block 1254 
communicates with the SDPS to update the RDPS' registry data record 900. 

[0107] If block 1250 determines that the user did not select to configure interests or filters, 
then processing continues to block 1256. If block 1256 determines the user selected to perform a 
situational location query, then the user specifies validated parameters (discussed with Fig. 15B) 
10 at block 1258. Thereafter, block 1260 communicates an appropriate formatted request to the 
SDPS. Thereafter, via a received system event, blocks 1318 through 1326 handle receipt, 
delivery, and RDPS user interface presentation of the content in a manner appropriate to the 
content type from the SDPS. Processing leaves block 1260 and returns to block 1112. 

[0108] If block 1256 determines that the user did not select to perform a situational location 
15 query, then processing continues to block 1264. If block 1264 determines that the user selected 
to query the number of known RDPS devices at a location(s) (i.e. a client count request), then 
block 1266 interfaces with the user to specify valid parameters including situational location 
information and time criteria, and processing continues to block 1260 which was described. A 
content specification parameter may also be specified for retrieving the situational location 
20 content as well. Time criteria embodiments include any time window in history, a current time 
window (of request, transmission of request, SDPS receipt of request, or processing the request), 
or a truncated precision time. Truncated precision time allows specifying time windows (e.g. 
12:04pm implies 4 minutes after 12:00pm and additionally any number of seconds up to and not 
including 5 minutes after 12:00pm). 

25 [0109] If block 1264 determines that the user did not select to query the number of RDPS 

devices at a location(s) (i.e. a client count request), then processing continues to block 1268. If 
block 1268 determines that the user selected to browse transmission history data, then block 
1270 interfaces with the user until he either exits, or selects information from the speed reference 
information field 978 from a transmission history data record 970. Preferably, block 1270 

30 permits scrolling transmission history data records 970 with fields columnized. If, at block 1272, 
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the user selected information of field 978, then block 1274 automatically performs the action, an 
automatic dialing of a telephone number, or automatic transposition to a web page. Speed 
reference information field 978 is preferably related to content that was delivered as referenced 
by rec id field 976. Thereafter, processing continues back to block 1112. If block 1272 
determines that the user exited from block 1270, then processing continues back to block 1112. 

[0110] If block 1268 determines that the user did not select to browse the transmission history 
data, then processing stops at block 1276. 

[0111] Note that some RDPS embodiments will not require blocks 1212 through 1228 because 
there may not be an active session required to have communications between the RDPS and 
SDPS. 

[0112] Fig. 13 depicts a flowchart for describing system event management processing aspects 
of a preferred embodiment of the RDPS of the present invention, in the context of candidate 
delivery event generation by the RDPS. System event management begins at block 1302, and 
continues to block 1304. If block 1304 determines the system event is a positional attribute 
15 change (e.g. location change) from the RDPS location management system, housekeeping is 
performed at block 1306 by pruning the location history data maintained at the RDPS. Pruning 
may be by time, number of entries, or other criteria. Thereafter, block 1308 determines if a 
CADE is to be generated. In one embodiment, block 1308 compares the current positional . 
attribute (e.g. location) with the former positional attribute of location history data record 920 
20 that contains an event posted YES/NO field 928 set to YES. The distance is calculated and then 
compared with the movement tolerance. Block 1308 also determines if there was a direction 
positional attribute change. Processing continues to block 1-310 where a location history data 
record 920 is appended to the location history data for the current location and/or direction with 
the event posted field 928 set according to what block 1308 determined. Block 1310 flows to 
25 block 1312. 

[0113] If block 1312 determines that a CADE is to be generated to the SDPS, then processing 
continues to block 1314. If block 1314 determines that the 'content delivery setting is set to 
enabled, then block 1316 formats and issues a CADE request to the SDPS, and processing 
continues to block 1 1 12 by way of off page connector 1 1000. 
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[01 14] If block 1314 determines that the content delivery setting is not enabled, then 
processing continues to block 1112. If block 1312 determines that a CADE is not to be 
generated, then processing continues to block 1112. 

[0115] If block 1304 determines that the system event was not for a RDPS positional attribute 
5 change from the location management system, then processing continues to block 1318. If block 
1318 determines that the system event is a transmission from the SDPS with content to deliver, 
or a content delivery indicator to content, then block 1320 performs housekeeping by pruning 
transmission history data records 970. Pruning is performed by time, number of entries, or some 
other criteria. Block 1320 flows to block 1322 where the transmission history data is checked to 

10 see if the rec id field 702 for the content or content delivery indicator, communicated with the 
system event, is already present in a transmission history data record 970. If the same content 
was already delivered, a rec id field 976 will match the rec id field 702 for pending presentation. 
The system event contains parameters including rec id field 702 with an indicator status for 
allowing the user to retrieve the content at a later time. If block 1324 determines the rec id field 

15 702 of the event is already contained in the transmission history data, then processing continues 
back to block 1112 with no delivery processing. If block 1324 determines it is not a redundant 
delivery, then block 1326 communicates with the SDPS for retrieval of the location field 704, 
direction field 706, content type field 710, short text field 714, and speed reference info field 
716. Any type of content is presented to the RDPS user interface in the appropriate manner. 

20 Various embodiments may limit types of content using a variety of methods, located at the RDPS 
or SDPS. Additionally, either content field 712 and linked content via content links field 722 is 
retrieved, or content delivery indicator(s) status is retrieved. Thereafter, block 1328 appends a 
transmission history data record 970 to the RDPS transmission history data, and processing 
continues to block 1 1 12. Blocks 1320 through 1326 handle all content (or indicator) delivery to 

25 the RDPS, preferably asynchronously to all other RDPS processing. 

[0116] If block 1318 determines that the system event was not for delivery, then processing 
stops at block 1330. 

[0117] An alternative embodiment to Fig. 13 processing will not check history for redundant 
content delivery. Or, a user may enable or disable the feature. 
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[0118] Block 1326 may also include applying client located filters for filtering out content. In 
such an embodiment, a filter criteria field 908 may not be required. 

[0119] The user of the RDPS may also modify the transmission history data to allow a 
redundant refresh. 

5 [0120] Fig. 14 depicts a flowchart for describing the content administration aspects of the 
present invention. An administrator, preferably a paying customer with rights to configure the 
deliverable content database, invokes the present invention administration interface. Fig. 14 is 
preferably a public access enabled, internet connected user interface for modifying the 
deliverable content database. The administrator may act on behalf of a paying customer. 
10 Processing begins at block 1402 and continues to block 1404 where the administrator is first 
authenticated as a valid user to perform administration. Then, block 1406 appropriately 
initializes the administration interface. Thereafter, block 1408 waits for user action (a user 
event). Once a user action is detected, processing continues. 

[0121] If block 1410 determines that the administrator selected to list his deliverable content 
15 database records 700, then the deliverable content database is searched using the administrator's 
authorization id against the authorization id field 720. Any deliverable content database records 
700 belonging to the administrator are put into a scrollable list at block 1414, and processing 
continues back to block 1408. Options are available for appropriately presenting the content, 
keywords data record 750, and linked content via content links field 722. The scrollable list 
20 preferably columnizes the displayable fields 702, 704, 706, 708, 710, 714, 716, 718, and 724. 

[0122] If block 1410 determines the user did not select to list his deliverable content database 
configurations, then processing continues to block 1416. If block 1416 determines that the user 
selected to delete a deliverable content data record 700 from the scrollable list, then block 1418 
deletes the record 700 from the content deliverable database along with any associated keywords 
25 data record 750, and linked content via content links field 722. Thereafter, block 1420 updates 
the scrollable list data, and processing continues back to block 1414. 

[0123] If block 1416 determines that the administrator did not select to delete, then processing 
continues to block 1422. If block 1422 determines the administrator selected to add a deliverable 
content database record 700, then block 1424 interfaces with the administrator for validated 
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entry. Thereafter, block 1426 generates a unique number record identifier for rec id field 702, 
block 1428 inserts into the deliverable content database, block 1430 inserts any associated 
keyword data record 750 to the keyword data, and processing continues back to block 1414. 
Keywords specification allows associating delivery content to a user's interests or filters in 
5 registration data for establishing a basis of delivery. Block 1424 provides appropriate interfaces 
for specifying and reviewing all types of content. Block 1428 additionally populates linked 
content if content links field 722 is used. Once a deliverable content database record 700 is 
inserted, it is instantly activated for candidate delivery. The delivery is proactive when the 
RDPS situational location is automatically determined. 

10 [0124] If block 1422 determines the user did not select to add a deliverable content database 
record 700, then processing continues to block 1432. If block 1432 determines that the user 
selected to modify location hierarchy data records 800, then the user modifies the data at block 
1436 and processing continues back to block 1408. If block 1432 determines the user did not 
select to modify location hierarchy data, then processing continues to block 1434 where other 

15 user actions are handled. Other user actions include scrolling, window manipulation, exiting the 
administration interface, or other navigation not relevant for discussion. Processing then 
continues back to block 1408. 

[0125] Preferably, the block 1432 option only presents itself to a special super-user 
administrator who is unlikely to cause problems for all other administrated configurations. It is 
20 very important that all data be maintained with integrity by blocks 141 8 and 1428. For example, 
a deliverable content database record 700 deleted should not be referenced by transmission 
history data 940. The rec id field 702 will no longer be valid. Fig. 14 processing may include an 
update deliverable database record option in alternative embodiments. 

[0126] Figs. 15A, 15B, and 15C depict flowcharts for service event handling aspects of a 
25 preferred embodiment of the SDPS of the present invention, in the context of candidate delivery 
event generation by the RDPS. SDPS processing relevant to the present invention begins at 
block 1502 when a service event (request) is posted (generated) to the SDPS, and continues to 
block 1504. All events are requests containing parameters including at least the device id 902 of 
the RDPS. Flowchart processing block discussions describe other parameters received, 
30 depending on the event (request) type. 
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[0127] If block 1504 determines that the event is an RDPS registration request, then block 
1506 accesses registration data to see if the RDPS unique device id is already present (i.e. 
already registered) in a device id field 902. Thereafter, if block 1508 determines the RDPS does 
not already have a registration data record 900 registered, then block 1510 inserts a registration 
5 data record 900 into registration data. Much of the information may be provided as parameters 
to the event, or alternatively, block 1506 communicates with the RDPS to gather needed field 
information. Then, block 1512 provides an acknowledgement to the RDPS, or an error if already 
registered. Processing continues to block 1514 by way of off page connector 15000. If block 
1514 determines that the RDPS was newly registered (i.e. an error was not provided), then block 

10 1516 searches the deliverable content database for delivery activation setting(s) field 718 with a 
"deliver on RDPS registration" bit enabled. Thereafter, if block 1517 determines there are 
deliverable content database records 700 with the bit set, then block 1518 processes applicable 
content transmission (see Fig. 16), and processing stops at block 1519. If block 1517 determines 
that there was no records, then processing stops at block 1519. If block 1514 determines that the 

1 5 RDPS was already registered (existing entry), then processing continues to block 1519. Thus, a 
situational location change may be an RDPS state changed to registered. 

[0128] If block 1 504 determines that the event was not a registration request, then processing 
continues to block 1520. If block 1520 determines that the event is a de-registration request, 
then block 1522 access the registration data for the device id field 902 provided with the event 

20 parameters, and if block 1524 determines one is found, then it is deleted at block 1526, and then 
an acknowledgement is provided at block 1512 with processing continuing from there as was 
described except block 1516 searches for the "deliver on RDPS termination bit" enabled. If 
block 1524 determines that a registration data record 900 was not found, then an error is 
provided at block 1512 and processing continues as previously described. Thus, a situational 

25 location change may be an RDPS state changed to terminated. 

[0129] If block 1520 determines that the event was not for an RDPS. de-registration, then 
processing continues to block 1528. If block 1528 determines that the RDPS user selected to 
retrieve content for a content delivery indicator previously sent to the RDPS by the SDPS, then 
block 1530 accesses the deliverable content database by the rec id field 702 provided as 
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parameters to the event, processing continues to block 1532 where the applicable content is 
processed (see Fig. 16), and processing stops at block 1534. 

[0130] If block 1528 determines that the event was not an indicator selection request, then 
processing continues to block 1536. If block 1536 determines the event is a CADE generated by 
5 the RDPS, then block 1538 parses parameters from the request, for example, location and 
direction. Thereafter, block 1540 completes determination of the situational location from the 
parameters and converts into a form suitable for searching the deliverable content database. 
Block 1540 consults location hierarchy data and determines the date/time to further refine the 
RDPS situational location. Then, block 1544 retrieves deliverable content database records 

10 using RDPS parameters and any applicable location hierarchy data records 800 to fields 704, 706 
and 708. Also used is data in interests field 906 and filter criteria 908 of the RDPS for 
comparing against keywords field 754 in keywords data associated with content deliverable 
database records 700. Delivery activation setting(s) field 718 is consulted as well. In some 
embodiments, the capabilities of the RDPS are maintained in field 904 to ensure no content of an 

15 inappropriate type is delivered. Thus, field 904 may also be utilized. If block 1546 determines 
that content was found, then block 1548 prunes transmission history data records 940 (by time, 
depth of records, etc.), block 1550 accesses the SDPS transmission history data, and block 1552 
continues. If block 1552 determines that the content was not already transmitted (device id field 
942 and rec id field 948 don't match any record in transmission history), then processing 

20 continues to block 1532 for processing described by Fig. 16. If block 1552 determines that the 
content was transmitted, then processing stops at block 1534. If block 1546 determines content 
applies, then processing stops at block 1534. 

[0131] If block 1536 determines that the event was not a CADE, then processing continues to 
block 1554 by way of off page connector 15002. If block 1554 determines that the event is for a 

25 situational location query, then block 1556 searches deliverable content database records 700 

with parameters from the RDPS: positional attribute parameters from the RDPS with the location 
field 704 and direction field 706, time criteria with time criteria field 708, and so on. All fields 
associated to record 700 are searchable through parameters: Block 1556 also applies location 
hierarchy data depending on a zoom specification parameter. The zoom specification allows 

30 control over the block 1556 search algorithm for whether or not to use hierarchy data, and 
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whether or not to check descending locations, ascending locations up to a maximum threshold 
parameter of content, both descending and ascending (respectively) up to a threshold of content, 
or neither ascending nor descending hierarchy data functionality. The maximum threshold 
parameter may be specified regardless, and optionally limits the amount of content to deliver to 
5 the RDPS by size, number of content instances, or number of hierarchical data record nestings to 
search. Further still block 1556 may use field 904 as described above, or the user's interest 
and/or filters as described above. Information for records found are transmitted as content to the 
RDPS at block 1558 (see Fig. 16) and processing stops at block 1572. 

[0132] If block 1554 determines that the event was not a situational location query, then 
10 processing continues to block 1562. If block 1562 determines that the request is a client count 
query request, then block 1564 retrieves the known number of RDPS devices at the specified 
situational location (e.g. location/direction) given specified time criteria; the number of 
transmission history data records 940 for unique values in rec id field 948 that contain a 
date/time stamp 952 according to the user's specified time criteria. A null time criteria 
15 parameter implies use the current time of processing the request with a truncated precision for a 
time window. Otherwise, a specified time window was entered by the user, or automatically 
inserted as a parameter by the RDPS or SDPS. Presence of the content specification parameter 
implies to additionally retrieve content from the deliverable content database as described by 
blocks 1538 through 1544. This allows providing information (e.g. graphical) to complement 
20 presentation of the total number of RDPS devices identified. Processing then continues to block 
1558 for transmitting the count as content. 

[0133] If block 1562 determines that the event was not a client count query request, then 
processing continues to block 1570 where any other SDPS event (request) is processed as is 
appropriate for the particular service application, and processing stops at block 1572. 

25 [0134] Fig. 16 depicts a flowchart for describing the content transmission aspects of the 
present invention. Fig. 16 describes processing of blocks 1518, 1532, 1558, 2018, 2032, and 
2058. Processing begins at block 1602, continues to block 1604 where registration data is 
accessed for communications bind information field 904 that is inserted when the RDPS 
registers, and then continues to block 1606. Block 1606 checks the size of the transmission 

30 destined for the RDPS. Thereafter, if block 1608 determines that the information is small 
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enough to not worry about transmission, then block 1610 transmits the situational location 
dependent information using field 904, block 1612 appends a transmission history data record 
940 to transmission history data, and processing stops at block 1616. Block 1610 may first 
compress and/or encrypt content transmission for efficient and/or safe communications that is 
5 then decompressed and/or decrypted by the RDPS at block 1326. Content may also by 

transmitted at block 1610 depending on capabilities of the RDPS maintained in field 904, for 
example, transmission speed, memory, storage space, etc. Thus, block 1610 may transmit using 
transmission delivery constraints of field 904. 

[0135] If block 1608 determines there may be too much information to unquestionably 
10 transmit, then block 1614 transmits content delivery indicator(s) information to the RDPS and 
processing continues to block 1612. Thus, the total size of the transmission is a transmission 
delivery constraint affecting the delivery information of the content. Of course, Fig. 16 could 
always transmit an indicator, or a transmission delivery constraint size could be configured to 
cause content delivery indicators delivered all, or most, of the time. 

15 [0136] Block 1608 may use a system size setting (e.g. number of bytes), or may use size 

information relative to RDPS capabilities maintained in communications bind information field 
904. 

SERVER DATA PROCESSING SYSTEM 
CANDIDATE DELIVERY EVENT GENERATION EMBODIMENT 
20 [0137] The reader should make note of the nearly identical descriptions and enumerations 

between the figures in different embodiments. The rightmost two digits of the block numbering 
have been preserved to facilitate correlation. Fig. 17 correlates Fig. 1 1, and so on. Fig. 14 and 
Fig. 16 are applicable to both embodiments: SDPS CADE generation and RDPS CADE 
generation. 

25 [0138] Fig. 1 7 depicts a flowchart for describing data processing system aspects relevant to a 
preferred embodiment of the RDPS of the present invention, in the context of candidate delivery 
event generation by the SDPS. When the RDPS is enabled, for example, by a power switch, 
system manager processing begins at block 1702 and continues to block 1704 where the system 
appropriately initializes, for example to default interfaces. Processing continues to block 1712. 

30 Block 1712 waits for a user event or system event. User interface management is coupled with 
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the system manager to enable a user to the RDPS. Upon detection of an event, block 1712 flows 
to block 1714 for any user event management processing. Should block 1714 processing return, 
block 1716 performs any system event management processing. Should processing of block 
1716 return, block 1718 handles the event appropriately as is relevant for other events of the 
5 RDPS, for example, user interface control of little interest to discussion of the present invention. 
Thereafter, block 1718 flows to block 1712 for processing as described. 

[0139] An alternate embodiment of Fig. 17 will implement a multithreaded system wherein 
events are handled asynchronously as they occur. 

[0140] Figs. 18A and 18B depict flowcharts for describing user event management processing 
10 aspects of a preferred embodiment of the RDPS of the present invention, in the context of 

candidate delivery event generation by the SDPS. User event management begins at block 1802 
and continues to block 1804. If block 1804 determines that the user event is powering the RDPS 
off, then block 1806 communicates with the SDPS to remove (if any) its RDPS data record 900 
from the registration data, block 1808 terminates any communication session gracefully (if 
15 required) depending on the RDPS, block 1810 saves settings, for example, the delivery setting 
for the next power on, and RDPS processing stops at block 1811. 

[0141] If block 1 804 determines the RDPS was not turned off, then processing continues to 
block 1812. If block 1812 determines that the user selected to enable communications with the 
SDPS, then block 1814 establishes communications with the SDPS (if not already established), 

20 and block 1816 consults the current delivery setting. In one embodiment, block 1814 through 
1820 maybe processed just as the result of a wireless device being powered on. If block 1816 
determines that the content delivery setting for receiving situational location dependent content is 
enabled, then block 1818 communicates with the SDPS for inserting a registry data record 900 
into the registry data. Thereafter, block 1820 sets a RDPS user interface indicator showing that 

25 communications to the SDPS is enabled, and processing returns to block 1712 of Figure 17 by 
way of off page connector 17000. If block 1816 determines the delivery setting is not enabled, 
then processing continues to block 1820. 

[0142] If block 1812 determines that the user did not select to enable communications to the 
SDPS, then processing continues to block 1822. If block 1822 determines that the user selected 
30 to disable SDPS communications, then block 1824 communicates with the SDPS to remove its 
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registry data record 900 from registry data, block 1826 terminates the communications session 
gracefully (if required) depending on the RDPS embodiment, block 1828 sets the 
communications to SDPS user interface indicator to disabled, and processing continues back to 
block ni2. In one embodiment, block 1824 through 1828 may be processed just as the result of 
5 a wireless device being powered off. 

[0143] If block 1822 determines the user did not select to disable communications to the 
SDPS, then processing continues to block 1830. If block 1830 determines that the user selected 
to modify the RDPS content delivery setting, then the user modifies the setting at block 1832, the 
delivery setting is set accordingly at block 1834. Preferably, blocks 1830/1832 allow a user to 

10 toggle the content delivery setting. No content will be delivered when this setting is disabled. 
Being registered with the SDPS constitutes being eligible for delivery. Alternative embodiments 
won't have such a feature. Block 1834 also sets an indicator in the user interface for displaying 
that setting, and block 1836 communicates with the SDPS to insert or remove its registry data 
record 900 should the setting be different than previous. Of course, appropriate error handling is 

15 performed by block 1836 if there is no communications enabled. Thereafter, processing 
continues to block 1712. 

[0144] If block 1830 determines that the user did not select to modify the content delivery 
setting, then processing continues to block 1844. If block 1844 determines that the user selected 
a content delivery indicator, as maintained in a transmission history data record 970 for 

20 deliverable content from the SDPS, then block 1846 communicates with the SDPS using the rec 
id field 976. In one embodiment, the user peruses the transmission history data in response to 
receiving a content delivery indicator from the SDPS. In another embodiment, correlation is 
maintained between individual user interface indicators to their associated transmission history 
data record 970 for allowing the user to simply select the indicator in the user interface for 

25 communicating with the SDPS to deliver the associated content. Providing a visual and/or 
audible presentation of the indicator is well known in the art and may be implemented with a 
variety of methods. Block 1 846 makes the request for content to the SDPS with the rec id 976. 
Thereafter, via a received system event, blocks 1918 through 1926 handle receipt, delivery, and 
RDPS user interface presentation of the content in a manner appropriate to the content type from 

30 the SDPS. Processing continues from block 1846 back to block 1712. 
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[0145] If block 1844 determines that the user did not select an indicator of deliverable content, 
then processing continues to block 1850 by way of off page connector 18000. If block 1850 
determines that the user selected to configure interests or filters, then block 1852 interfaces with 
the user to configure interests or filters which are saved locally at block 1854, and processing 
5 continues back to block 1712 by way of off page connector 17000, Any configured interests and 
filters are communicated to the SDPS at blocks 1818 and 1836 as part of registration. Interests 
field 906 and filter criteria field 908 are set with data configured at block 1852. The RDPS must 
de-register and re-register with new settings. In an alternative embodiment, block 1854 
communicates with the SDPS to update the RDPS' registry data record 900. 

10 [0146] If block 1850 determines that the user did not select to configure interests or filters, 

then processing continues to block 1856. If block 1856 determines the user selected to perform a 
situational location query, then the user specifies validated parameters (discussed with Fig. 20B) 
at block 1858. Thereafter, block 1860 communicates an appropriate formatted request to the 
SDPS, and thereafter via a received system event, blocks 1918 through 1926 handle receipt, 

15 delivery, and RDPS user interface presentation of the content in a manner appropriate to the 
content type from the SDPS. Processing leaves block 1860 and returns to block 1712. 

[0147] If block 1856 determines that the user did not select to perform a situational location 
query, then processing continues to block 1864. If block 1864 determines that the user selected 
to query the number of known RDPS devices at a location(s) (i.e. a client count request), then 

20 block 1866 interfaces with the user to specify valid parameters including situational location 
information and time criteria, and processing continues to block 1860 which was described. A 
content specification parameter may also be specified for retrieving the situational location 
content as well. Time criteria embodiments include any time window in history, a current time 
window (of request, transmission of request, SDPS receipt of request, or processing the request), 

25 or a truncated precision time. If block 1 864 determines that the user did not select to 

query the number of RDPS devices at a location(s) (i.e. a client count request), then processing 
continues to block 1868. If block 1868 determines that the user selected to browse transmission 
history data, then block 1870 interfaces with the user until he either exits, or selects information 
from the speed reference information field 978 from a transmission history data record 970. 

30 Preferably, block 1870 permits scrolling transmission history data records 970 with fields 

41 



columnized. If, at block 1872, the user selected information of field 978, then block 1874 
automatically performs the action, an automatic dialing of a telephone number, or automatic 
transposition to a web page. Speed reference information field 978 is preferably related to 
content that was delivered as referenced by rec id field 976. Thereafter, processing continues 
5 back to block 1712. If block 1872 determines that the user exited from block 1870, then 
processing continues back to block 1712. 

[0148] If block 1868 determines that the user did not select to browse the transmission history 
data, then processing stops at block 1876. 

[0149] Note that some RDPS embodiments will not require blocks 1812 through 1828 because 
10 there may not be an active session required to have communications between the RDPS and 
SDPS. In one embodiment, the movement tolerance is communicated to the SDPS at blocks 
1818 and 1836, and then inserted to movement tolerance field 910. 

[0150] Fig. 19 depicts a flowchart for describing system event management processing aspects 
of a preferred embodiment of the RDPS of the present invention, in the context of candidate 

15 delivery event generation by the SDPS. System event management begins at block 1902, and 
continues to block 1918. If block 1918 determines that the system event is a transmission from 
the SDPS with content to deliver, or a content delivery indicator to content, then block 1920 
performs housekeeping by pruning transmission history data records 970. Pruning is performed 
by time, number of entries, or some other criteria. Block 1920 flows to block 1922 where the 

20 transmission history data is checked to see if the rec id field 702 for the content or content 
delivery indicator, communicated with the system event, is -already present in a transmission 
history data record 970. If the same content was already delivered, a rec id field 976 will match 
the rec id field 702 for pending presentation. The system event contains parameters including 
rec id field 702 with an indicator status for allowing the user to retrieve the content at a later 

25 time. If block 1924 determines the rec id field 702 of the event is already contained in the 
transmission history data, then processing continues back to block 1712 with no delivery 
processing. If block 1924 determines it is not a redundant delivery, then block 1926 
communicates with the SDPS for retrieval of the location field 704, direction field 706, content 
type field 710, short text field 714, and speed reference info field 716. Any type of content is 

30 presented to the RDPS user interface in the appropriate manner. Various embodiments may limit 
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types of content using a variety of methods, located at the RDPS or SDPS. Additionally, either 
content field 712 and linked content via content links field 722 are retrieved, or content delivery 
indicator status is retrieved. Thereafter, block 1928 appends a transmission history data record 
970 to the RDPS transmission history data, and processing continues to block 1712. Blocks 
5 1920 through 1926 handle all content (or indicator) delivery to the RDPS, preferably 
asynchronously to all other RDPS processing. 

[0151] If block 1918 determines that the system event was not for delivery, then processing 
stops at block 1930. 

[0152] An alternative embodiment to Fig. 19 processing will not check history for redundant 
10 content delivery. Or, a user may enable or disable the feature. 

[0153] Block 1926 may also include applying client located filters for filtering out content. In 
such an embodiment, a filter criteria field 908 may not be required. 

[0154] The user of the RDPS may also modify the transmission history data to allow a 
redundant refresh. 

15 [0155] Figs. 20A, 20B, and 20C depict flowcharts for service event handling aspects of a 

preferred embodiment of the SDPS of the present invention, in the context of candidate delivery 
event generation by the SDPS. SDPS processing relevant to the present invention begins at 
block 2002 when a service event (request) is posted (generated) to the SDPS, and continues to 
block 2004. All events are requests containing parameters including at least the device id 902 of 

20 the RDPS. Flowchart processing block discussions describe other parameters received, 
depending on the event (request) type. 

[0156] If block 2004 determines that the event is an RDPS registration request, then block 
2006 accesses registration data to see if the RDPS unique device id is already present (i.e. 
already registered) in a device id field 902. Thereafter, if block 2008 determines the RDPS does 
25 not already have a registration data record 900 registered, then block 2010 inserts a registration 
data record 900 into registration data. Much of the information may be provided as parameters 
to the event, or alternatively, block 2006 communicates with the RDPS to gather needed field 
information. Then, block 2012 provides an acknowledgement to the RDPS, or an error if already 
registered. Processing continues to block 2014 by way of off page connector 20000. If block 
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2014 determines that the RDPS was newly registered (i.e. an error was not provided), then block 
2016 searches the deliverable content database for delivery.activation setting(s) field 718 with a 
"deliver on RDPS registration" bit enabled. Thereafter, if block 2017 determines there are 
deliverable content database records 700 with the bit set, then block 2018 processes applicable 
5 content transmission (see Fig. 16), and processing stops at block 2019. If block 2017 determines 
that there was no records, then processing stops at block 2019. If block 2014 determines that the 
RDPS was already registered (existing entry), then processing continues to block 2019. Thus, a 
situational location change may be an RDPS state changed to registered. 

[0157] If block 2004 determines that the event was not a registration request, then processing 
10 continues to block 2020. If block 2020 determines that the event is a de-registration request, 
then block 2022 access the registration data for the device id field 902 provided with the event 
parameters, and if block 2024 determines one is found, then it is deleted at block 2026, and then 
an acknowledgement is provided at block 2012 with processing continuing from there as was 
described except block 2016 searches for the "deliver on RDPS termination bit" enabled. If 
1 5 block 2024 determines that a registration data record 900 was not found, then an error is 

provided at block 2012 and processing continues as previously described. Thus, a situational 
location change may be an RDPS state changed to terminated. 

[0158] If block 2020 determines that the event was not for an RDPS de-registration, then 
processing continues to block 2028. If block 2028 determines that the RDPS user selected to 
20 retrieve content for a content delivery indicator previously sent to the RDPS by the SDPS, then 
block 2030 accesses the deliverable content database by the rec id field 702 provided as 
parameters to the event, processing continues to block 2032 where the applicable content is 
processed (see Fig. 16), and processing stops at block 2034. 

[0159] If block 2028 determines that the event was not an indicator selection request, then 
25 processing continues to block 2036. If block 2036 determines the event is a CADE generated by 
a service of, or to, the SDPS (see Fig. 3B, Fig. 5B, and Fig. 6), then block 2038 parses 
parameters from the request, for example, location and direction. Thereafter, block 2040 
completes determination of the situational location from the parameters and converts into a form 
suitable for searching the deliverable content database. Block 2040 consults location hierarchy 
30 data and determines the date/time to further refine the RDPS situational location. Then, block 
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2044 retrieves deliverable content database records using RDPS parameters and any applicable 
location hierarchy data records 800 to fields 704, 706 and 708. Also used is data in interests 
field 906 and filter criteria 908 of the RDPS for comparing against keywords field 754 in 
keywords data associated with content deliverable database records 700. Delivery activation 
5 setting(s) field 718 is consulted as well. In some embodiments, the capabilities of the RDPS are 
maintained in field 904 to ensure no content of an inappropriate type is delivered. Thus, field 
904 may also be utilized. If block 2046 determines that content was found, then block 2048 
prunes transmission history data records 940 (by time, depth of records, etc.), block 2050 
accesses the SDPS transmission history data, and block 2052 continues. If block 2052 
10 determines that the content was not already transmitted (device id field 942 and rec id field 948 
don't match any record in transmission history), then processing continues to block 2032 for 
processing described by Fig. 16. If block 2052 determines that the content was transmitted, then 
processing stops at block 2034. If block 2046 determines content applies, then processing stops 
at block 2034. 

15 [0160] If block 2036 determines that the event was not a CADE, then processing continues to 
block 2054 by way of off page connector 20002. If block 2054 determines that the event is for a 
situational location query, then block 2056 searches deliverable content database records 700 
with parameters from the RDPS: positional attribute parameters from the RDPS with the location 
field 704 and direction field 706, time criteria with time criteria field 708, and so on. All fields 

20 associated to record 700 are searchable through parameters. Block 2056 also applies location 
hierarchy data depending on a zoom specification parameter. The zoom specification allows 
control over the block 2056 search algorithm for whether or not to use hierarchy data, and 
whether or not to check descending locations, ascending locations up to a maximum threshold 
parameter of content, both descending and ascending (respectively) up to a threshold of content, 

25 or neither ascending nor descending hierarchy data functionality. The maximum threshold 

parameter may be specified regardless, and optionally limits the amount of content to deliver to 
the RDPS by size, number of content instances, or number of hierarchical data record nestings to 
search. Further still block 2056 may use field 904 as described above, or the user's interest 
and/or filters as described above. Information for records found is transmitted as content to the 

30 RDPS at block 2058 (see Fig. 16) and processing stops at block 2072. 
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[0161] If block 2054 determines that the event was not a situational location query, then 
processing continues to block 2062. If block 2062 determines that the request is a client count 
query request, then block 2064 retrieves the known number of RDPS devices at the specified 
situational location (e.g. location/direction) given specified time criteria; the number of location 
5 history data records 920 for unique values in rec id field 922 that contain a date/time stamp 930 
according to the user's specified time criteria. A null time criteria parameter implies use the 
current time of processing the request with a truncated precision for a time window. Otherwise, a 
specified time window was entered by the user, or automatically inserted as a parameter by the 
RDPS or SDPS. Presence of the content specification parameter implies to additionally retrieve 
1 0 content from the deliverable content database as described by blocks 2038 through 2044. This 
allows providing information (e.g. graphical) to complement presentation of the total number of 
RDPS devices identified. Processing then continues to block 2058 for transmitting the count as 
content. 

[0162] If block 2062 determines that the event was not a client count query request, then 
15 processing continues to block 2070 where any other SDPS event (request) is processed as is 
appropriate for the particular service application, and processing stops at block 2072. Fig. 16 
depicts a flowchart for describing the content transmission aspects. Fig. 16 describes processing 
of blocks 2018, 2032, and 2058. 

[0163] In any of the embodiments described above, a performance conscious implementation 
20 of the present invention including a cache may be pursued given the RDPS has appropriate 
capability. Without departing from the spirit and scope of the invention, deliverable content 
database records 700, and joined data from them, may be stored at an RDPS. The SDPS may 
transmit a compression of the data to the RDPS for decompression and local maintaining. 
Transmission may be at registration and/or performed asynchronously to the RDPS as necessary. 
25 Thus, the deliverable content database, and joined data from it, will be accessed locally to the 
RDPS to prevent real-time communication of what could be large amounts of content. Fig. 14 
processing would include updating any RDPS with a local cache when configuration was 
complete. 

[0164] While various embodiments of the present invention have been described above, it 
30 should be understood that they have been presented by way of example only, and not limitation. 
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Thus, the breadth and scope of the present invention should not be limited by any of the above- 
described exemplary embodiments, but should be defined only in accordance with the following 
claims and their equivalents. 
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